General computing platforms and entertainment platforms (including computers, video game consoles, portable video game devices, cell phones, personal digital assistants (“PDAs”) and the like) (hereinafter referred to generally as “processing platform”) typically use a virtual memory address space that exceeds the platform's addressable physical random access memory (RAM). Using virtual memory provides many well known benefits.
A virtual memory addressing scheme enables a processor to perform operations (e.g., reads, writes, bitwise operations, arithmetic operations, and the like) using a virtual memory address that typically exceeds the processor's available random access memory (“RAM”). Such virtual memory addresses are translated to physical addresses using a memory management system. For example, a processing platform may include a memory management unit (“MMU”) to manage a virtual address space, providing features such as virtual to physical address translation. A conventional MMU splits the virtual address space and physical address space into segments of memory called pages. Any page size may be chosen; however, typically a page size of 4 kilobytes to 32 kilobytes is used.
When a program running on a processing platform attempts to access a virtual memory address, the MMU attempts to facilitate the requested access, for example, by performing one or more of the following operations: (i) determining if the memory corresponding to the virtual memory address resides in the cache; (ii) translating the virtual memory address to a physical memory address; (iii) determining if the requesting process has sufficient privileges to access the referenced address; and (iv) determining whether the referenced memory is paged out to secondary storage. If the MMU is unable to provide access to the referenced memory address through translation to physical memory or through the cache, then a fault may be raised. If, for example, a page fault is raised because a requested virtual memory address is paged out to secondary storage, an error handler may simply load the page to physical memory and continue.
However, if the fault is caused by insufficient privileges or illegal requests, then the system may not be able to recover and a crash may occur. When a crash occurs various information may be stored for later debugging and analysis.
One problem with debugging a crash is a lack of information regarding the events that led to the crash. A programmer may only have information regarding the state of the platform at the time of the crash; however, the event that ultimately caused the crash may have occurred earlier. One solution to this problem is to configure a program to save certain state information every time a procedure is executed. While this technique may be effective, such debugging granularity creates significant overhead. For programs where timing may be important, the added overhead may disrupt such timing, hindering the debugging process. Accordingly, there is a need for an improved debugging technique that provides sufficient granularity to identify and correct problems without excessively increasing system overhead.